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Ingeniería de software 
orientada a aspectos 


Objetivos 


El objetivo de este capítulo es introducirlo al desarrollo de 
software orientado a aspectos, que se basa en la separación 

de competencias, intereses, asuntos o propiedades del sistema 
(separation of concerns). Al estudiar este capítulo: 


m comprenderá por qué la separación de intereses es un buen 
principio guía para el desarrollo de software; 


m seintroducirá a las ideas fundamentales que subyacen en 
los aspectos y el desarrollo de software orientado a aspectos; 


m conocerá cómo puede usar un enfoque orientado a aspectos 
para la ingeniería de requerimientos, el diseño de software 
y la programación; 


m estará al tanto de las dificultades de poner a prueba sistemas 
orientados a aspectos. 


Contenido 
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21.2 Aspectos, puntos de enlace y puntos de corte 
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En la mayoría de los grandes sistemas, las relaciones entre los requerimientos y com- 
ponentes del programa son complejas. Un solo requerimiento puede implementarse 
mediante algunos componentes y cada uno de éstos puede incluir elementos de varios 
requerimientos. En la práctica, esto significa que implementar un cambio a los reque- 
rimientos implica comprender y modificar varios componentes. Otra posibilidad es 
que un componente puede proporcionar alguna funcionalidad central, pero también 
incluir código que implemente muchos requerimientos de sistema. Aun cuando parezca 
haber un significativo potencial de reutilización, podría ser costoso reutilizar tales com- 
ponentes. La reutilización tal vez implique modificarlos para eliminar el código adicional 
de manera que no se asocie con la funcionalidad central del componente. 

La ingeniería de software orientada a aspectos (AOSE, por las siglas de Aspect-Orien- 
ted Software Engineering) es un enfoque al desarrollo de software que está destinado a 
enfrentar este problema y así elaborar programas más fáciles de mantener y reutilizar. 
AOSE se basa en abstracciones llamadas aspectos, que ponen en marcha la funcionali- 
dad de sistema que pueden requerirse en varios lugares diferentes en un programa. Los 
aspectos encapsulan funcionalidad que atraviesa y coexiste con otra funcionalidad que 
se incluye en un sistema. Se usan al lado de otras abstracciones como objetos y métodos. 
Un programa ejecutable orientado a aspectos se crea automáticamente al combinar (tejer, 
weave) objetos, métodos y aspectos, de acuerdo con las especificaciones comprendidas 
en el código fuente del programa. 

Una importante característica de los aspectos es que incluyen una definición sobre 
dónde deben incluirse en un programa, además del código que implementa la com- 
petencia que atraviesa. Puede especificar que el código transversal (cross-cutting) 
debe incluirse antes o después de una llamada de método específico o al acceder a un 
atributo. En esencia, el aspecto se entrelaza en el programa central para crear un nuevo 
sistema aumentado. 

El beneficio principal de un enfoque orientado a aspectos es que soporta la separación 
de competencias. Como se explica en la sección 21.1, la separación de competencias en 
elementos independientes, en vez de incluir diferentes competencias en la misma abs- 
tracción lógica, es una buena práctica de la ingeniería de software. Al representar las 
competencias transversales como aspectos, éstas pueden comprenderse, reutilizarse y 
modificarse de manera independiente, sin tomar en cuenta dónde se use el código. Por 
ejemplo, la autenticación de usuario puede representarse como un aspecto que solicite 
un nombre de usuario y una contraseña. Esto puede integrarse automáticamente en el 
programa siempre que se requiera autenticación. 

Considere que tiene un requerimiento en el que se precise autenticación del usuario 
antes de realizar cualquier cambio de información personal en una base de datos. Puede 
describir esto en un aspecto al enunciar que debe incluir un código de autenticación antes de 
cada solicitud de métodos que actualicen datos personales. Posteriormente, puede ampliar 
el requerimiento de autenticación a todas las actualizaciones de la base de datos. Esto se 
implementa fácilmente al modificar el aspecto. Sólo se cambia la definición de dónde debe 
incorporarse el código de autenticación en el sistema. No tiene que buscar a través del 
sistema para encontrar todas las incidencias de dichos métodos. Por consiguiente, tendrá 
menor probabilidad de cometer errores e introducir vulnerabilidades de seguridad acciden- 
tales en su programa. 

La investigación y el desarrollo en la orientación a aspectos se enfocaron esencialmente 
en la programación orientada a aspectos. Se han diseñado lenguajes de programación orien- 
tados a aspectos, como AspectJ (Colyer y Clement, 2005; Colyer et al., 2005; Kiczales 
et al., 2001; Laddad, 2003a; Laddad, 2003b), que extienden la programación orientada 
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a objetos para incluir aspectos. Las grandes compañías usan la programación orienta- 
da a aspectos en sus procesos de producción de software (Colyer y Clement, 2005). Sin 
embargo, las competencias transversales son igualmente problemáticas en otras etapas del 
proceso de desarrollo de software. Ahora los investigadores indagan sobre cómo utilizar la 
orientación a aspectos en la ingeniería de requerimientos de sistema y diseño de sistemas, y 
la forma de poner a prueba y verificar programas orientados a aspectos. 

Aquí se incluye una discusión de AOSE porque su enfoque en la separación de las 
competencias es una importante manera de pensar y estructurar un sistema de soft- 
ware. Aunque se han implementado algunos sistemas a gran escala mediante un enfoque 
orientado a aspectos, el uso de aspectos no es todavía parte de la ingeniería de soft- 
ware convencional. Como en todas las nuevas tecnologías, sus defensores se enfocan 
en los beneficios más que en los problemas y costos. Aunque transcurrirá algún tiempo 
antes de que la AOSE se emplee de modo rutinario al lado de otros enfoques de la inge- 
niería de software, es importante la idea de separar las competencias que subyacen en 
la AOSE. Considerar la separación de las competencias es un buen enfoque general para la 
ingeniería de software. 

En las secciones restantes del capítulo se tratan los conceptos que son parte de la 
AOSE, y se examinan las ventajas y desventajas de usar un enfoque orientado a aspectos 
en diferentes etapas del proceso de desarrollo de software. Como la meta del capítulo es 
ayudar a comprender los conceptos subyacentes en la AOSE, no nos adentraremos en 
detalles de algún enfoque específico o lenguaje de programación orientado a aspectos. 


La separación de intereses 


La separación de competencias o intereses (concerns) es un principio clave del diseño 
e implementación de software. Significa que usted debe organizar su software de modo 
que cada elemento en el programa (clase, método, procedimiento, etcétera) realice una 
función y sólo una función. Entonces podrá enfocarse en ese elemento sin considerar 
los otros elementos en el programa. Es posible comprender cada parte del programa al 
conocer su competencia, sin necesidad de entender otros elementos. Cuando se requieren 
cambios, éstos se localizan en un pequeño número de elementos. 

La importancia de separar las competencias se reconoció en las etapas iniciales de 
la ciencia de la computación. Las subrutinas, que encapsulan una unidad de funciona- 
lidad, se inventaron a principios de la década de 1950, y se han diseñado mecanismos 
subsecuentes de estructuración del programa, tales como procedimientos y clases de 
objetos, con la finalidad de proporcionar mejores mecanismos para realizar la separación 
de competencias. Sin embargo, todos estos mecanismos tienen problemas para hacer 
frente a ciertos tipos de competencias que cruzan otras competencias. Tales competen- 
cias transversales no pueden ubicarse mediante mecanismos de estructuración como 
objetos o funciones. Los aspectos se inventaron para ayudar a gestionar estas competen- 
cias transversales. 

Aunque en general se acordó que la separación de competencias es una buena práctica 
de ingeniería de software, resulta muy difícil identificar con exactitud lo que se entiende 
realmente por competencia. En ocasiones, ésta se define como una noción funcional (es 
decir, una competencia es algún elemento funcional en un sistema). Como alternativa, 
puede definirse de manera muy general como “cualquier pieza de interés o el propósito 
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de un programa”, aunque ninguna de estas definiciones es particularmente útil en la prác- 
tica. Sin duda, las competencias son más que simplemente elementos funcionales, pero 
una definición más general es tan vaga, que en realidad resulta inútil. 

Según el autor, la mayoría de los intentos por definir las competencias son problemá- 
ticos porque tratan de relacionar las competencias a programas. De hecho, como explican 
Jacobson y Ng (2004), las competencias se consideran en realidad como reflejos de los 
requerimientos y las prioridades de las partes interesadas en el sistema. El rendimiento del 
sistema puede ser una competencia porque los usuarios quieren tener una respuesta rápida 
de un sistema; algunas partes interesadas tal vez se preocupen porque el sistema incluya 
una particular funcionalidad; las compañías que soportan un sistema pueden inclinarse en 
que sea fácil de mantener. Por lo tanto, una competencia puede definirse como algo que es 
de interés o significado para un participante o un grupo de participantes. 

Si piensa en las competencias como una forma de organizar los requerimientos, 
observará por qué es una buena práctica un enfoque de la implementación que separa 
las competencias en diferentes elementos de programa. Se considera más fácil rastrear las 
competencias, expresadas como un requerimiento o un conjunto relacionado de requeri- 
mientos, a partir de los componentes del programa, que implementar dichas competen- 
cias. Si los requerimientos cambian, entonces es evidente la parte del programa que debe 
cambiar. 

Existen varios tipos diferentes de competencias o intereses para el participante: 


1. Competencias funcionales, que se relacionan con la funcionalidad específica a 
incluir en un sistema. Por ejemplo, en un sistema de control ferroviario, una compe- 
tencia funcional específica consiste en el frenado del tren. 


2. Competencias de calidad del servicio, las cuales se relacionan con el comporta- 
miento no funcional de un sistema. Estas incluyen características como rendimiento, 
fiabilidad y disponibilidad. 


3. Competencias de política, que se relacionan con políticas generales que rigen el 
uso de un sistema. Las limitaciones políticas incluyen competencias de seguridad y 
protección, y las competencias relacionadas con las reglas de negocio. 


4. Competencias de sistema, las cuales se relacionan con atributos del sistema como un 
todo, tales como su mantenibilidad o configurabilidad. 


5. Competencias organizacionales, que se relacionan con las metas y prioridades de 
la organización. Entre ellas se incluyen producir un sistema dentro de presupuesto, 
usar los activos de software existentes y mantener la imagen de la organización. 


Las competencias centrales de un sistema son aquellas competencias funcionales rela- 
cionadas con su propósito primario. Así, para un sistema de información de pacientes en 
un hospital, las competencias funcionales centrales son la creación, edición, recuperación 
y gestión de registros de pacientes. Además de las competencias centrales, los grandes 
sistemas tienen también competencias funcionales secundarias. Éstas pueden incluir fun- 
cionalidad que comparte información con las competencias centrales, o que se requiere 
para que el sistema pueda cumplir con sus requerimientos no funcionales. 

Por ejemplo, considere un sistema que tenga un requerimiento para ofrecer acceso con- 
currente a un buffer compartido. Un proceso agrega datos al buffer y otro proceso toma 
datos del mismo buffer. Este buffer compartido es parte de un sistema de adquisición de 
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Figura 21.1 
Competencias 
transversales 


Requerimientos 
Requerimientos Requerimientos de gestión de 
de cliente nuevo de cuenta clientes 


Competencias 
transversales 


Requerimientos de seguridad 


Requerimientos de recuperación 


Competencias centrales 


datos en el que un proceso productor pone datos en el buffer y un proceso consumidor 
toma los datos éste. Aquí la competencia central es mantener un buffer compartido de 
manera que la funcionalidad central está asociada con agregar y eliminar elementos del 
buffer. Sin embargo, para garantizar que los procesos productor y consumidor no inter- 
fieran entre sí, existe una competencia secundaria esencial de sincronización. El sistema 
debe diseñarse de forma que el proceso productor no pueda sobrescribir datos que no se 
hayan consumido, ni el proceso consumidor pueda tomar datos de un buffer vacío. 

Aparte de estas competencias secundarias, otras competencias como calidad de servi- 
cio y políticas organizacionales reflejan requerimientos esenciales del sistema. En gene- 
ral, se trata de competencias del sistema: se aplican al sistema como un todo en lugar de 
implementarse a requerimientos individuales o a la realización de dichos requerimientos 
en un programa. Son las llamadas competencias transversales (cross-cutting), para dis- 
tinguirlas de las competencias centrales. Las competencias funcionales secundarias tam- 
bién pueden ser transversales, aunque no siempre atraviesan todo el sistema; en vez de 
ello, se asocian con agrupamientos de competencias centrales que ofrecen funcionalidad 
relacionada. 

Las competencias transversales se muestran en la figura 21.1, la cual se basa en un 
ejemplo de un sistema de banca por Internet. Este sistema tiene requerimientos relacio- 
nados con nuevos clientes, como comprobación de crédito y verificación de dirección. 
Asimismo, posee requerimientos relacionados con la administración de los clientes exis- 
tentes y la gestión de cuentas de los clientes. Todas ellas son competencias centrales 
que se asocian con el propósito primario del sistema: proveer un servicio de banca por 
Internet. Sin embargo, el sistema también cuenta con requerimientos de seguridad con 
base en la política de seguridad del banco, y requerimientos de recuperación para garanti- 
zar que los datos no se pierdan en caso de una falla del sistema. Se trata de competencias 
transversales, ya que pueden influir en la implementación de todos los otros requerimien- 
tos del sistema. 

Las abstracciones de lenguaje de programación, tales como procedimientos y cla- 
ses, son el mecanismo que se usa normalmente para organizar y estructurar las compe- 
tencias centrales de un sistema. No obstante, la implementación de las competencias 
centrales en lenguajes de programación convencionales incluye por lo general código 
adicional para implementar las competencias transversales, funcionales, de calidad de 
servicio y de políticas. Esto conduce a dos fenómenos indeseables: enredos (tangling) y 
dispersión (scattering). 
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synchronized void put (SensorRecord rec ) 


{ 
// Comprueba que haya espacio en el buffer; espera si no 
if ( numberOfEntries == bufsize) 
wait () 


// Agrega registro al final del buffer 


store [back] 


= new SensorRecord (rec.sensorld, rec.sensorVal) ; 


back = back + 1 ; 
// Si está al final del buffer, la siguiente entrada está al principio 
1f (back == bufsize) 


back = 0 


numberO0fEntries = numberOfEntries + 1 ; 
// indica que el buffer está disponible 


notify (O) ; 
) // put 


Figura 21.2 Enredos 
de código de gestión 
y sincronización 

de buffer 


El enredo (tangling) ocurre cuando un módulo en un sistema incluye código que 
implementa diferentes requerimientos de sistema. El ejemplo de la figura 21.2, que es 
una implementación simplificada de parte del código para un sistema de buffer limitado, 
ilustra este fenómeno. La figura 21.2 es una implementación de la operación put (poner) 
que añade un ítem al buffer. Sin embargo, si el buffer está lleno, debe esperar hasta que 
una correspondiente operación get (conseguir) elimine un ítem del buffer. Los detalles 
no tienen importancia; en esencia, se usan las llamadas wait() y notify() para sincronizar 
las operaciones put y get. El código que soporta la principal competencia (en este caso, 
poner un registro en el buffer) está enredado con código que implementa sincronización. 
El código de sincronización, que se asocia con la competencia secundaria de asegurar 
exclusión mutua, debe incluirse en todos los métodos que acceden al buffer compartido. 
El código asociado con la competencia de sincronización se muestra en la figura 21.2. 

El fenómeno relacionado de dispersión (scattering) ocurre cuando la implementación 
de una competencia individual (un requerimiento lógico o un conjunto de requerimien- 
tos) se dispersa a través de varios componentes del programa. Probablemente esto ocu- 
rre cuando se implementan requerimientos relacionados con competencias funcionales 
secundarias o competencias de política. 

Por ejemplo, suponga que un sistema de gestión de registros médicos, como el MHC- 
PMS, tiene algunos componentes que se ocupan de gestionar la información del personal, 
los medicamentos, las consultas, las imágenes médicas, los diagnósticos y tratamien- 
tos. Es decir, implementan la competencia central del sistema: mantener registros de los 
pacientes. El sistema puede configurarse para diferentes tipos de clínicas al seleccionar 
los componentes que proporcionan la funcionalidad necesaria para la clínica. 

Sin embargo, suponga que existe también una importante competencia secundaria que 
es el mantenimiento de información estadística; el proveedor de código de salud quiere 
registrar detalles de cuántos pacientes se admiten y se dan de alta cada mes, cuántos 
pacientes mueren, qué medicamentos se prescriben, las razones de las consultas, etcétera. 
Dichos requerimientos tienen que implementarse agregando código que vuelva anóni- 
mos los datos (para mantener la privacidad de los pacientes) y los escriba en una base de 
datos estadística. Un componente estadístico procesa los datos estadísticos y genera los 
reportes que se requieren. 
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Figura 21.3 Dispersión 
de métodos que 
implementan 
competencias 
secundarias 


Paciente Imagen Consulta 


<decls atributo> <decls atributo> <decls atributo> 


getName () getModality () makeAppoint () 
editName () archive () cancelAppoint () 
getAddress () getDate () assignNurse () 
editAddress () editDate () bookEquip () 


anonymize () 
saveConsult () 


saveDiagnosis () 
saveType () 


anonymize () 


Esto se ilustra en la figura 21.3. El diagrama muestra ejemplos de tres clases que 
pueden incluirse en el sistema de registro de pacientes junto con algunos de los méto- 
dos centrales para gestionar información de pacientes. El área sombrada representa los 
métodos que se requieren para implementar la competencia estadística secundaria. Como 
se observa, esta competencia estadística se dispersa a lo largo de las otras competencias 
centrales. 

Los problemas con la dispersión y el enredo ocurren cuando cambian los requeri- 
mientos iniciales del sistema. Por ejemplo, suponga que deben recopilarse nuevos datos 
estadísticos en el sistema de registro de pacientes. Los cambios al sistema no se ubican 
todos en un lugar y, por lo tanto, uno tiene que emplear tiempo buscando los componen- 
tes en el sistema que deban cambiarse. Entonces es preciso modificar cada uno de estos 
componentes para incorporar los cambios requeridos. Esto puede ser costoso debido al 
tiempo que se necesita para analizar los componentes y, luego, para realizar y probar los 
cambios. Siempre existe la posibilidad de que se pierda algo de código que se debe cam- 
biar y, por consiguiente, las estadísticas serán incorrectas. Más aún, cuanto más severos 
sean los cambios que deban realizarse, aumentará la probabilidad de que se cometa una 
falla y se introduzcan errores en el software. 


Aspectos, puntos de enlace y puntos de corte 


En esta sección se introducen los nuevos y más importantes conceptos asociados con el 
desarrollo de software orientado a aspectos y se ilustran mediante ejemplos del MHC- 
PMS. La terminología que se utiliza fue introducida por los desarrolladores de AspectJ a 
finales de la década de 1990. Sin embargo, los conceptos son de aplicación general y no 
específicos del lenguaje de programación AspectJ. La figura 21.4 resume los términos 
clave que hay que entender. 

Un sistema de registros médicos como el MCH-PMS incluye componentes que mane- 
jan información relacionada lógicamente de pacientes. El componente patient (paciente) 
mantiene información personal acerca del paciente, el componente medication (medica- 
ción) conserva información sobre los medicamentos que deben prescribirse, etcétera. Al 
diseñar el sistema con un enfoque basado en componentes, pueden configurarse diferen- 
tes instancias del sistema. Por ejemplo, podría configurarse una versión para cada tipo de 
clínica en la que sólo se permita a los médicos prescribir medicamentos relevantes para 
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Figura 21.4 
Terminología usada 
en la ingeniería de 
software orientada 
a aspectos 


Término Definición 
consejo (advice) El código que implementa una competencia. 


aspecto (aspect) Una abstracción de programa que define una competencia 
transversal. Incluye la definición de un punto de corte 
(pointcut) y el consejo (advice) asociado con dicha 
competencia. 


punto de enlace Un evento en un programa en ejecución en que puede 
(join point) ejecutarse el consejo asociado con un aspecto. 
modelo de punto de El conjunto de eventos que se pueden referenciar en un 


enlace (join point model) punto de corte. 


punto de corte (pointcut) Un enunciado, incluido en un aspecto, que define los 
puntos de enlace en que debe ejecutarse el consejo del 
aspecto asociado. 


tejido (weaving) La incorporación de código del consejo (advice) en los 
puntos de enlace (join point) especificados por un tejedor 
(weaving) de aspectos 


dicha clínica. Esto simplifica la labor del personal clínico y reduce las posibilidades de 
que un médico prescriba por error el medicamento equivocado. 

Sin embargo, esta organización significa que la información en la base de datos debe 
actualizarse desde algunos lugares diferentes en el sistema. Por ejemplo, la información 
del paciente puede modificarse cuando sus datos personales cambian, al prescribirle un 
nuevo medicamento, al asignarle un nuevo especialista, etcétera. En aras de la sencillez, 
suponga que todos los componentes del sistema usan una estrategia de nomenclatura 
consistente y que todas las actualizaciones de la base de datos se implementan mediante 
métodos que comienzan con “update”. Por lo tanto, existen métodos en el sistema como: 


updatePersonalInformation (patientld, infoupdate) 


updateMedication (patientld, medicationupdate) 


El paciente se identifica mediante patientld y los cambios a realizar se codifican en el 
segundo parámetro; los detalles de esta codificación no son importantes para este ejemplo. 
Las actualizaciones se realizan por el personal del hospital, que ingresa al sistema. 

Imagine que ocurre una violación de la seguridad y se modifica maliciosamente infor- 
mación del paciente. Tal vez alguien dejó por accidente su computadora conectada al 
sistema y una persona no autorizada entró al mismo. Alternativamente, una persona auto- 
rizada puede tener acceso y modificar maliciosamente la información del paciente. Para 
reducir la probabilidad de que esto ocurra nuevamente, se introduce una nueva política 
de seguridad. Antes de realizar cualquier cambio a la base de datos del paciente, la per- 
sona que solicita el cambio de nuevo debe autenticarse en el sistema. Los detalles de 
quién hace el cambio también se registran en un archivo aparte. Esto ayudará a rastrear 
los problemas si volvieran a ocurrir. 

Una forma de implementar esta nueva política es modificar el método update en ca- 
da componente para llamar a otros métodos y realizar authentication (autenticación) y 
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aspect authentication 


( 


perores call (publie vore Upaawmes (s.)1) M ésto es Un Puto de corre 


( 


// éste es el consejo -advice- que debe ejecutarse cuando se teje -weaving- en 
// el sistema en ejecución 


int tries 


=0:; 


string userPassword = Password.Get ( tries ) ; 
while (tries < 3 88 userPassword != thisUser.password ( ) ) 


( 


// permite 3 intentos para ingresar la contraseña correcta 
tries = tries +1; 
userPassword = Password.Get ( tries ) ; 


) 


if (userPassword != thisUser.password ( )) then 
//si la contraseña es equivocada, supone que el usuario olvidó su contraseña 
System.Logout (thisUser.uid) s 


) 


) // authentication 


Figura 21.5 

Un aspecto de la 
autenticación (aspect 
authentication) 


logging (conexión lógica). O bien, el sistema podría modificarse de forma que cada vez 
que se solicite un método update, las llamadas del método se agreguen antes del llamado 
para hacer authentication, y después para registrar los cambios efectuados. Sin embargo, 
ninguna de éstas es una excelente solución para este problema: 


1. El primer enfoque conduce a una implementación enredada. Lógicamente, actua- 
lizar una base de datos, autenticar la fuente de una actualización y registrar los de- 
talles de la actualización son competencias (concerns) no relacionadas. Tal vez 
usted quiera incluir authentication en alguna otra parte del sistema sin ingresar al 
sistema o desee registrar las acciones separadas de la acción update (actualización). 
El mismo código authentication y logging debe incluirse dentro de varios métodos 
diferentes. 


2. El enfoque alternativo conduce a una implementación dispersa. Si explícitamente 
comprende llamadas de método para hacer authentication y logging antes y después 
de cada llamada a los métodos update, entonces este código se incluye en el sistema 
en varios lugares diferentes. 


Authentication y logging cortan transversalmente las competencias centrales del sis- 
tema y posiblemente deban incluirse en varios lugares diferentes. En un sistema orien- 
tado a aspectos, es posible representar estas competencias transversales como aspectos 
separados. Un aspecto incluye una especificación de dónde debe tejerse en el programa 
la competencia transversal, y el código para implementar dicha competencia. Esto se 
ilustra en la figura 21.5, que define un aspecto authentication. La notación que se usa en 
este ejemplo sigue el estilo de AspectJ, pero usa una sintaxis simplificada que debe ser 
comprensible sin conocimiento de Java o de AspectJ. 

Los aspectos son completamente diferentes de otras abstracciones del programa en 
las que el aspecto en sí incluye una especificación en torno a dónde debe ejecutarse. 
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Con otras abstracciones, tales como los métodos, hay una separación clara entre la defi- 
nición de la abstracción y su uso. Al examinar el método, no es posible decir de dónde 
se le llamará; las llamadas pueden ser desde cualquier parte que abarque el método. En 
contraste, los aspectos incluyen un “punto de corte” (pointcut): un enunciado que define 
dónde se tejerá el aspecto en el programa. 

En este ejemplo, el punto de corte es un enunciado simple: 


before: call (public void update* (..)) 


El significado de esto es que antes de la ejecución de cualquier método cuyo nombre 
comience con la cadena update, seguido por cualquier otra secuencia de caracteres, debe 
ejecutarse el código en el aspecto después de la definición de punto de corte. El carácter 
asterisco (*) se llama comodín (wildcard) y coincide con cualquier cadena de caracteres que 
se permite en los identificadores. El código a ejecutar se conoce como el “advice” (consejo) 
y es la implementación de la competencia transversal. En este caso, el consejo obtiene una 
contraseña de la persona que solicita el cambio y verifica que coincida con la contraseña del 
usuario que ingresó recientemente al sistema. Si no concuerda, se desconecta al usuario y no 
procede la actualización. 

La habilidad para especificar, con puntos de corte, dónde debe ejecutarse el código es 
la característica distintiva de los aspectos. Sin embargo, para comprender qué significan 
los puntos de corte, es necesario entender otro concepto: la idea de un punto de enlace. 
Un punto de enlace (join point) es un evento que ocurre durante la ejecución de un pro- 
grama; podría ser una llamada de método, la inicialización de una variable, el almacena- 
miento de una actualización, etcétera. 

Existen muchos tipos posibles de eventos que pueden ocurrir durante la ejecución del 
programa. Un modelo de punto de enlace define el conjunto de eventos que se pueden 
referenciar en un programa orientado a aspectos. Los modelos de punto de enlace no 
son estandarizados y cada lenguaje de programación orientado a aspectos tiene su pro- 
pio modelo de punto de enlace. Por ejemplo, en los eventos AspectJ, que son parte del 
modelo de punto de enlace, se incluyen: 


m eventos de llamada: llamadas a un método o constructor; 

m eventos de ejecución: ejecución de un método o constructor; 
m eventos de inicialización: inicialización de clase u objeto; 

m eventos de datos: acceso o actualización de un archivo; 


m eventos de excepciones: manejo de una excepción. 


Un punto de corte identifica el evento o eventos específicos (por ejemplo, una llamada 
a un procedimiento nombrado) con los que debe asociarse un consejo. Esto significa que 
es posible tejer consejos en un programa en muchos contextos diferentes, dependiendo 
del modelo de punto de enlace que soporte: 


1. Los consejos pueden incluirse antes de la ejecución de un método específico, una 
lista de métodos nombrados o una lista de métodos cuyos nombres coincidan con 
una especificación de patrón (como update*). 
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2. Los consejos pueden incluirse después de un regreso normal o excepcional de un 
método. En el ejemplo que se muestra en la figura 21.5, se podría definir un punto 
de corte que ejecute el código logging después de todas las llamadas a métodos 
update. 


3. Los consejos pueden incluirse cuando se modifica un archivo en un objeto; se 
podrían incluir consejos para monitorizar o cambiar ese archivo. 


La inclusión de consejos en los puntos de enlace especificados en los puntos de corte 
es responsabilidad de un tejedor de aspectos. Los tejedores de aspectos son extensiones 
de compiladores que procesan la definición de los aspectos y las clases de objetos y 
métodos que definen el sistema. El tejedor genera un nuevo programa con los aspectos 
incluidos en los puntos de enlace especificados. Los aspectos se integran de forma que 
las competencias transversales se ejecuten en los lugares correctos del sistema final. 

La figura 21.6 ilustra este tejido de aspectos para los aspectos authentication y logging 
que deben incluirse en el MHC-PMS. Hay tres enfoques diferentes al tejido de aspectos: 


1. Preprocesamiento de código fuente, en el que un tejedor toma entrada de código 
fuente y genera nuevo código fuente en un lenguaje como Java o C++, que luego 
pueden compilarse usando el compilador de lenguaje estándar. Este enfoque se 
adoptó para el lenguaje AspectX con su asociado XWeaver (Birrer et al., 2005). 


2. Tejido de tiempo de vinculación, en el que el compilador se modifica para incluir 
un tejedor de aspectos. Un lenguaje orientado a aspectos, como AspectJ, se pro- 
cesa y genera bytecode Java estándar. Entonces éste puede ejecutarse directamente 
mediante un intérprete Java o procesarse aún más para generar código de máquina 
nativo. 


3. Tejido dinámico en tiempo de ejecución. En este caso, se monitorizan los puntos de 
enlace y, cuando ocurre un evento referenciado en un punto de corte, se integra el 
consejo correspondiente con el programa en ejecución. 


El enfoque usado más comúnmente para el tejido de aspectos es el tejido de tiempo 
de vinculación, pues esto permite la implementación eficiente de los aspectos sin una 
gran carga de tiempo de ejecución. El tejido dinámico es el enfoque más flexible, pero 
puede incurrir en significativas penalizaciones de rendimiento durante la ejecución del 
programa. Actualmente el preprocesamiento de código fuente se usa poco. 
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Ingeniería de software con aspectos 


Los aspectos se introdujeron originalmente con un lenguaje de programación de secuen- 
cias, pero, como se estudió, la noción de competencias es una que realmente proviene de 
los requerimientos del sistema. Por lo tanto, tiene sentido adoptar un enfoque orientado a 
aspectos en todas las etapas del proceso de desarrollo del sistema. En las primeras etapas 
de la ingeniería de software, adoptar un enfoque orientado a aspectos significa usar la 
noción de separación de competencias como base para considerar los requerimientos y el 
diseño del sistema. Identificar y modelar las competencias debe ser parte de la ingeniería 
de requerimientos y de diseño. Los lenguajes de programación orientados a aspectos, 
pues, ofrecen el soporte tecnológico para mantener la separación de las competencias en 
su implementación del sistema. 

Cuando se diseña un sistema, Jacobson y Ng (2004) sugieren que debe considerarse 
que el sistema soporte diferentes competencias de las partes interesadas como un sistema 
central más extensiones. Esto se ilustra en la figura 21.7, donde se usan paquetes UML 
para representar tanto el núcleo como las extensiones. El sistema central es un conjunto 
de funciones del sistema que implementan el propósito esencial del sistema. Por consi- 
guiente, si el propósito de un sistema particular es mantener información de los pacientes 
en un hospital, el sistema central en tal caso ofrece un medio para crear, editar, gestionar 
y acceder a una base de datos de registros de pacientes. Las extensiones del sistema 
central reflejan competencias adicionales de las partes interesadas, que deben integrarse 
con el sistema central. Por ejemplo, es importante que un sistema de información médica 
mantenga la confidencialidad de la información de los pacientes, de manera que una 
extensión podría ocuparse del control del acceso, otra de la encriptación, etcétera. 

Existen algunos tipos diferentes de extensiones que se derivan de los distintos tipos de 
competencias que se estudiaron en la sección 21.1. 


1. Extensiones funcionales secundarias Agregan capacidades adicionales a la funcio- 
nalidad que ofrece el sistema central. En este caso, con el ejemplo del MHC-PMS, la 
producción de informes sobre los medicamentos prescritos en el mes anterior sería 
una extensión funcional secundaria para un sistema de información de pacientes. 


2. Extensiones de política Agregan capacidades funcionales para soportar políticas 
de la organización. Las extensiones que adicionan características de seguridad son 
ejemplos de extensiones de política. 


3. Extensiones QoS Agregan capacidades funcionales para ayudar a alcanzar los 
requerimientos de calidad del servicio que se especificaron para el sistema. Por 
ejemplo, una extensión podría implementar una caché para reducir el número 
de accesos a la base de datos o automatizar los respaldos para recuperación en caso de 
una falla del sistema. 


4. Extensiones de infraestructura Estas extensiones agregan capacidades funcionales 
para soportar la implementación de un sistema en alguna plataforma de implemen- 
tación específica. Por ejemplo, en un sistema de información de pacientes, pueden 
usarse extensiones de infraestructura para implementar la interfaz al sistema de ges- 
tión de base de datos subyacente. Pueden hacerse cambios a esta interfaz modifi- 
cando las extensiones de infraestructura asociadas. 
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Las extensiones siempre agregan algún tipo de funcionalidad o características adicio- 
nales al sistema central. Los aspectos son una forma de implementar dichas extensiones 
y pueden combinarse con la funcionalidad del sistema central mediante las instalacio- 
nes de tejido en el entorno de programación orientado a aspectos. 


Ingeniería de requerimientos orientados a competencias 


Como se sugirió en la sección 21.1, las competencias reflejan los requerimientos de las 
partes interesadas. Dichas competencias pueden reflejar la funcionalidad requerida por 
un participante, la calidad de servicio del sistema, políticas o conflictos de la organiza- 
ción que se relacionan con los atributos del sistema como un todo. Por lo tanto, tiene sen- 
tido adoptar un enfoque a la ingeniería de requerimientos que identifique y especifique 
las diferentes competencias de las partes interesadas. A veces se usa el término “aspectos 
tempranos” para referirse al uso de aspectos en etapas tempranas del ciclo de vida del 
software donde se enfatiza la separación de competencias. 

Por muchos años se ha reconocido la importancia de separar las competencias durante 
la ingeniería de requerimientos. Los puntos de vista que representan diferentes pers- 
pectivas sistémicas se incorporan en algunos métodos de ingeniería de requerimientos 
(Easterbrook y Nuseibeh, 1996; Finkelstein ef al., 1992; Kotonya y Sommerville, 1996). 
Estos métodos separan las competencias de diferentes partes interesadas. Los puntos de 
vista reflejan la distinta funcionalidad que requieren diferentes grupos de participantes. 

Sin embargo, también existen requerimientos que atraviesan todos los puntos de vista, 
como se muestra en la figura 21.8. Este diagrama indica que los puntos de vista pueden ser 
de diferentes tipos, pero las competencias transversales (como regulación, confiabilidad y 
seguridad) generan requerimientos que pueden tener repercusiones en todos los puntos de 
vista del sistema. Ésta fue la principal consideración que hizo el autor en el trabajo para 
desarrollar el método Pre View (Sommerville y Sawyer, 1997; Sommerville et al., 1998), 
que incluía pasos para identificar competencias transversales no funcionales. 

Para desarrollar un sistema que esté organizado en el estilo que se presenta en la figura 
21.7, hay que identificar los requerimientos para el sistema central además de los reque- 
rimientos para las extensiones del sistema. Un enfoque a la ingeniería de requerimientos 
orientado a puntos de vista, en el que cada punto de vista representa los requerimientos de 
grupos de participantes relacionados, es una forma de separar competencias centrales y 
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secundarias. Si los requerimientos se organizan de acuerdo con el punto de vista de las 
partes interesadas, entonces usted podrá analizarlos para descubrir requerimientos rela- 
cionados que aparezcan en todos o la mayoría de los puntos de vista. Éstos representan 
la funcionalidad central del sistema. Otros requerimientos de puntos de vista pueden ser 
requerimientos que sean específicos a dicho punto de vista. Éstos pueden implementarse 
como extensiones a la funcionalidad central. 

Por ejemplo, imagine que usted desarrolla un sistema de software para rastrear equipo 
especializado que usan los servicios de emergencia. El equipo se ubica en diferentes 
lugares de una región o estado y, en caso de una emergencia, como una inundación o 
un terremoto, los servicios de emergencia emplean el sistema para descubrir qué equipo 
está disponible cerca del sitio del problema. La figura 21.9 muestra bosquejos de reque- 
rimientos de tres posibles puntos de vista para tal sistema. 

En este ejemplo se observa que los participantes que representan los diferentes puntos 
de vista deben encontrar ítems de equipo específicos, navegar el equipo disponible en 
cada ubicación, e ingresar/sacar equipo del almacén. Por lo tanto, éstos son requerimien- 
tos para el sistema central. Los requerimientos secundarios soportan las necesidades más 
específicas de cada punto de vista. Existen requerimientos secundarios para extensiones 
del sistema que soportan el uso, la gestión y el mantenimiento del equipo. 

Los requerimientos funcionales secundarios que se identifican a partir de cualquier 
punto de vista no atraviesan necesariamente los requerimientos de otros puntos de vista. 
Por ejemplo, sólo el punto de vista de mantenimiento está interesado por completar regis- 
tros de mantenimiento. Dichos requerimientos reflejan las necesidades de ese punto de 
vista y tales competencias tal vez no sean compartidas por otros puntos de vista. Sin 
embargo, además de los requerimientos funcionales secundarios, existen competencias 
transversales que generan requerimientos de importancia para algunos o todos los puntos 
de vista. Con frecuencia, éstos reflejan requerimientos de política y calidad de servicio 
que se aplican al sistema como un todo. Según se estudió en el capítulo 4, se trata de 
requerimientos no funcionales, como los requerimientos de seguridad, rendimiento y 
costo. 

En el sistema de inventario de equipo, un ejemplo de competencia transversal es la dis- 
ponibilidad del sistema. Las emergencias pueden ocurrir con poca o ninguna advertencia. 
El salvar vidas puede requerir que el equipo especial se despliegue tan rápido como sea 
posible. Por lo tanto, los requerimientos de confiabilidad para el sistema de inventario 
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1. Usuarios del servicio de emergencia 


1.1 Encontrar un tipo específico de equipo (por ejemplo, un elevador de cargas pesadas). 
1.2 Ver equipo disponible en un almacén específico. 

1.3 Retirar equipo. 

1.4 Ingresar equipo. 

1.5 Ordenar equipo para transportarlo a una emergencia. 

1.6 Enviar reporte de daño. 

1.7 Encontrar un almacén cerca de la emergencia. 


2. Planificadores de emergencias 


2.1 Encontrar un tipo específico de equipo. 

2.2 Ver equipo disponible en una ubicación específica. 
2.3 Ingresar/retirar equipo de un almacén. 

2.4 Mover el equipo de un almacén a otro. 

2.5 Ordenar nuevo equipo. 


3. Personal de mantenimiento 


3.1 Ingresar/retirar equipo para mantenimiento. 

3.2 Ver equipo disponible en cada almacén. 

3.3 Encontrar un tipo específico de equipo. 

3.4 Ver calendario de mantenimiento para un ítem de equipo. 

3.5 Completar registro de mantenimiento para un ítem de equipo. 

3.6 Mostrar todos los ítems en un almacén que requieran mantenimiento. 


Figura 21.9 Puntos Je equipo incluyen requerimientos para un alto nivel de disponibilidad del sistema. En la 

devista enur figura 21.10 se muestran algunos ejemplos de estos requerimientos de confiabilidad, con 

sistema de inventario las razones asociadas. Al usar estos requerimientos es posible identificar las extensiones 

de equipo de la funcionalidad central para logging de transacción y reporte de estatus. Esto facilita 
la identificación de problemas y el cambio a un sistema de respaldo. 

El resultado del proceso de ingeniería de requerimientos debe ser un conjunto de 

requerimientos que se estructuran en torno a la noción de un sistema central más exten- 


Figura 21.10 siones. Por ejemplo, en el sistema de inventario, los ejemplos de requerimientos centrales 
Requerimientos pueden ser: 

relacionados con la 

disponibilidad para el 


sistema de inventario C.1 El sistema debe permitir que los usuarios autorizados vean la descripción de algún 
de equipo ítem de equipo en el inventario de servicios de emergencia. 
DISP.1 Debe existir un sistema “de espera caliente” (hot standby) en una ubicación que esté 
geográficamente bien separada del sistema principal. 
Razón: La emergencia puede afectar la ubicación principal del sistema. 
DISP.1.1 Todas las transacciones deben registrarse en el sitio del sistema principal y en el sitio de espera 
remoto. 
Razón: Esto permite que dichas transacciones se reproduzcan y que las bases de datos del sistema sean 


consistentes. 


DISP.1.2 Cada cinco minutos el sistema debe enviar información de estatus al sistema de la sala de 
control de emergencias. 

Razón: Los operadores del sistema de la sala de control pueden cambiar a la posición de espera caliente 
cuando el sistema principal no esté disponible. 
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participantes. 


21.3.2 


a) Puntos de vista 


La noción de puntos de vista se introdujo en el capítulo 4, donde se explicó el modo en que pueden usarse 
los puntos de vista como una forma de estructurar los requerimientos de diferentes partes interesadas. Al 
usar puntos de vista, es posible identificar los requerimientos del sistema central de cada agrupamiento de 
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C.2 El sistema debe incluir una instalación de búsqueda para permitir a los usua- 
rios autorizados indagar inventarios individuales o el inventario completo de un ítem 
específico de equipo o un tipo específico de equipo. 


El sistema también puede incluir una extensión que tenga el propósito de apoyar la 
procuración y sustitución de equipo. Los requerimientos para esta extensión pueden ser: 


E1.1 Debe ser posible que usuarios autorizados realicen pedidos a proveedores acre- 
ditados para sustituir los ítems de equipo. 


El1.1.1 Cuando se ordene un ítem de equipo, debe asignarse a un inventario específico 
y marcarlo en dicho inventario como “en pedido”. 


Como regla general, hay que evitar tener demasiadas competencias o extensiones al 
sistema. Esto simplemente confunde al lector y podría conducir a un diseño prematuro. 
Además, limita la libertad de los diseñadores y es posible que dé por resultado un diseño 
de sistema que no cumpla sus requerimientos de calidad de servicio. 


Diseño y programación orientada a aspectos 


El diseño orientado a aspectos es el proceso de diseñar un sistema que utilice los aspec- 
tos para implementar las competencias transversales y extensiones que se identificaron 
durante el proceso de ingeniería de requerimientos. En esta etapa es necesario traducir 
las competencias que se relacionan con el problema que hay que resolver a los aspectos 
correspondientes en el programa que implementará la solución. También es indispensa- 
ble comprender cómo se combinarán estos aspectos con otros componentes de sistema y 
garantizar que no surjan ambigiiedades de composición. 

El enunciado de requerimientos de alto nivel brinda una base para identificar algunas 
extensiones del sistema que puedan implementarse como aspectos. Entonces es necesa- 
rio desarrollarlos con mayor detalle para identificar más extensiones y comprender la 
funcionalidad solicitada. Una forma de hacerlo es identificar un conjunto de casos de uso 
(que se explicaron en los capítulos 4 y 5) asociados con cada punto de vista. Los modelos 
de caso de uso se enfocan en la interacción y son más detallados que los requerimientos de 
usuario. Puede considerarlos como un puente entre los requerimientos y el diseño. En 
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Figura 21.11 Casos 
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un modelo de caso de uso se describen los pasos de cada interacción de usuario y así se 
comienza a identificar y definir las clases en el sistema. 

Jacobson y Ng (2004) escribieron un libro que explica cómo pueden usarse los casos 
de uso en la ingeniería de software orientada a aspectos. Sugieren que cada caso de uso 
representa un aspecto, y proponen extensiones al enfoque de caso de uso para apoyar los 
puntos de enlace y puntos de corte. También introducen la noción de rebanadas de caso 
de uso y módulos de caso de uso. Ellos incluyen fragmentos de clases que implementan 
un aspecto. Pueden combinarse para crear el sistema completo. 

La figura 21.11 muestra ejemplos de tres casos de uso que pueden ser parte del sis- 
tema de gestión de inventario. Éstos reflejan las competencias de agregar equipo a un 
inventario y ordenar equipo. La solicitud de equipo y la adición de equipo son compe- 
tencias relacionadas. Una vez entregados los artículos solicitados, deben agregarse al 
inventario y entregarse a uno de los almacenes de equipo. 

El UML incluye ya la noción de casos de uso de extensión. Un caso de uso de exten- 
sión extiende la funcionalidad hacia otro caso de uso. La figura 21.12 indica cómo la 
colocación de una petición de equipo extiende el caso de uso central para agregar equipo 
a un almacén específico. Si el equipo a agregar no existe, puede solicitarse y agregarse 
al almacén cuando se entregue el equipo. Durante el desarrollo de los modelos de caso 
de uso habrá que buscar las características comunes y, donde sea posible, estructurar 
los casos de uso como casos centrales más extensiones. Las características transversa- 
les, como el registro lógico de todas las transacciones, también pueden representarse 
como casos de uso de extensión. Jacobson y Ng discuten cómo las extensiones de este 
tipo pueden implementarse como aspectos. 
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El desarrollo de un proceso efectivo para el diseño orientado a aspectos resulta esen- 


cial si el diseño orientado a aspectos debe aceptarse y usarse. Se sugiere que un proceso 
de diseño orientado a aspectos incluya las actividades que se muestran en la figura 21.13. 
Dichas actividades son: 


1. 


Diseño del sistema central En esta etapa se diseña la arquitectura del sistema para 
soportar la funcionalidad central del sistema. La arquitectura debe considerar tam- 
bién los requerimientos de calidad de servicio, como los requerimientos de rendi- 
miento y confiabilidad. 


Identificación y diseño de aspectos A partir de las extensiones identificadas en los 
requerimientos del sistema, habrá que efectuar un análisis para ver si son aspectos en 
sí mismos o si deben descomponerse en varios aspectos. Una vez identificados los 
aspectos, pueden diseñarse por separado tomando en cuenta el diseño de las caracte- 
rísticas del sistema central. 


Diseño de composición En esta etapa se analiza el sistema central y los diseños de 
aspectos para descubrir dónde deben combinarse los aspectos con el sistema central. 
En esencia, se identifican los puntos de enlace en un programa donde se tejerán los 
aspectos. 


Análisis y resolución de conflictos Un problema con los aspectos es que pueden 
interferir entre sí cuando se combinan con el sistema central. Los conflictos ocu- 
rren al haber un choque de puntos de corte con diferentes aspectos que especifican 
que deben combinarse en el mismo punto del programa. Sin embargo, puede haber 
conflictos más sutiles. Cuando los aspectos se diseñan de manera independiente, 
realizan suposiciones acerca de la funcionalidad del sistema central que debe modi- 
ficarse. No obstante, cuando se combinan varios aspectos, un aspecto podría afectar 
la funcionalidad del sistema de una forma no anticipada por otros aspectos. Entonces 
el comportamiento global del sistema quizá no sea el esperado. 


Diseño de nombre Ésta es una importante actividad de diseño que define están- 
dares para nombrar las entidades del programa. Esto es importante para evitar el 
problema de puntos de corte accidentales. Éstos ocurren cuando, en algún punto 
de enlace del programa, el nombre coincide accidentalmente con el de un patrón de 
punto de corte. En consecuencia, el consejo se aplica de manera no intencional a 
dicho punto. Desde luego, esto es indeseable y puede conducir a un comportamiento 
inesperado del programa. Por lo tanto, habrá que diseñar un esquema de nomencla- 
tura que minimice la probabilidad de que esto ocurra. 
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Este proceso, naturalmente, es un proceso iterativo en el que usted hace propuestas 
de diseño iniciales y luego las refina conforme analiza y comprende los conflictos del 
diseño. Por lo general, esperaría refinar las extensiones identificadas en los requerimien- 
tos a un mayor número de aspectos. 

El resultado del proceso de diseño orientado a aspectos es un modelo de diseño orien- 
tado a aspectos. Esto puede expresarse en una versión extendida del UML que incluye 
nuevas sentencias específicas de aspectos, tales como las propuestas por Clarke y 
Baniassad (2005) y Jacobson y Ng (2004). Los elementos esenciales del “UML de aspec- 
tos” son un medio para modelar aspectos y especificar los puntos de enlace donde deben 
combinarse los consejos de aspecto con el sistema central. 

La figura 21.14 es un ejemplo de un modelo de diseño orientado a aspectos. Se usó el 
estereotipo UML para un aspecto propuesto por Jacobson y Ng. La figura 21.14 muestra 
el sistema central para un inventario de servicios de emergencia más algunos aspectos 
que pueden combinarse con dicho núcleo. Se exponen algunas clases del sistema central 
y algunos aspectos. Ésta es una imagen simplificada; un modelo completo incluiría más 
clases y aspectos. Observe cómo se usaron las notas UML para ofrecer información adi- 
cional acerca de las clases que son atravesadas (cross-cut) por algunos aspectos. 

La figura 21.15 es un modelo más detallado de un aspecto. Desde luego, antes de 
diseñar aspectos, hay que tener un diseño del sistema central. Como aquí no hay espacio 
para mostrar esto, se hicieron algunas suposiciones acerca de las clases y los métodos en 
el sistema central. 

La primera sección del aspecto establece los puntos de corte que especifican dónde 
se combinarán con el sistema central. Por ejemplo, el primer punto de corte especifica 
que el aspecto puede combinarse en el punto de enlace call getltemInfo(..). La siguiente 
sección define las extensiones que implementa el aspecto. En este ejemplo, el enunciado 
de la extensión puede leerse como: 


En el método viewltem, después de llamar al método getltemInfo, debe incluirse 
un llamado al método displayHistory para mostrar el registro de mantenimiento. 


La programación orientada a aspectos (AOP, por las siglas de aspect-oriented pro- 
gramming) se inició en los laboratorios PARC de Xerox, en 1997, con el desarrollo del 
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lenguaje de programación AspectJ. Éste sigue siendo el lenguaje orientado a aspectos 
usado más ampliamente, aunque se han implementado también extensiones orienta- 
das a aspectos de otros lenguajes, tales como C# y C++. Además, se han desarrollado 
otros lenguajes experimentales para soportar la separación explícita de las competencias 
y la composición de competencias, y existe implementación experimental de AOP en el 
framework .NET. La programación orientada a aspectos se cubre de manera extensa en 
otros libros (Colyer et al., 2005; Gradecki y Lezeiki, 2003; Laddad, 2003b). 

Si usted siguió un enfoque orientado a aspectos para diseñar su sistema, ya identificó 
la funcionalidad central y las extensiones para que dicha funcionalidad se implemente 
como aspectos transversales. El enfoque del proceso de programación debe ser entonces 
escribir código que implemente la funcionalidad central y de extensión, y, de manera fun- 
damental, especificar los puntos de corte en los aspectos para que el consejo del aspecto 
se teja en el código base en los lugares correctos. 

Es muy importante especificar de manera correcta los puntos de corte, pues éstos 
definen dónde se combinarán los consejos de aspecto con la funcionalidad central. Si se 
comete un error en la especificación del punto de corte, entonces el consejo del aspecto 
se tejerá en el programa en el lugar equivocado. Esto podría conducir a un comporta- 
miento inesperado e impredecible del programa. Es esencial respetar los estándares de 
nomenclatura establecidos durante el diseño del sistema. También es necesario revisar 
todos los aspectos para garantizar que no ocurra interferencia de aspectos si dos o más 
aspectos se tejen en el sistema central en el mismo punto de enlace. En general, es mejor 
evitar esto por completo, pero, en ocasiones, puede ser la mejor forma para implementar 
una competencia. En tales circunstancias, hay que asegurarse de que los aspectos son 
completamente independientes. El comportamiento del programa no debe depender del 
orden en que los aspectos se tejan en el programa. 


Verificación y validación 


Como se estudió en el capítulo 8, la verificación y la validación implican demostrar que 
un programa cumple su especificación (verificación) y satisface las necesidades reales de 
las partes interesadas (validación). Las técnicas de verificación estática se enfocan en aná- 
lisis manual o automatizado del código fuente del programa. La validación o las pruebas 
dinámicas se usan para descubrir defectos en el programa o demostrar que el programa 
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cumple con sus requerimientos. Cuando la detección de defectos es el objetivo, el proceso 
de prueba puede guiarse mediante el conocimiento del código fuente del programa. Las 
métricas de cobertura de prueba muestran la efectividad de las pruebas para hacer que los 
enunciados del código fuente sean ejecutables. 

Para los sistemas orientados a aspectos, los procesos de las pruebas de validación 
no son diferentes a los de cualquier otro sistema. El programa final ejecutable se trata 
como una caja negra y se diseñan pruebas para demostrar si el sistema cumple o no con 
los requerimientos. Sin embargo, el uso de aspectos causa problemas reales con las ins- 
pecciones de programa y las pruebas de caja blanca, mientras que el código fuente del 
programa se usa para identificar potenciales pruebas de defecto. 

Las inspecciones de programa, que se describen en el capítulo 24, implican un equipo 
de lectores que observan el código fuente de un programa para descubrir defectos que 
haya introducido el programador. Es una técnica muy efectiva de descubrimiento de 
defectos. Sin embargo, los programas orientados a aspectos no pueden leerse secuencial- 
mente (esto es, de arriba abajo). Por lo tanto, es más difícil que la gente los comprenda. 

Un lineamiento general para la comprensibilidad del programa es que un lector pueda 
leer un programa de izquierda a derecha sin tener que cambiar la atención hacia otras 
partes del código. Esto lo hace más sencillo para los lectores y también hace menos 
probable que los programadores cometan errores mientras su atención se enfoca en una 
sola sección de código. Mejorar la legibilidad del programa fue una razón clave para la 
introducción de la programación estructurada (Dijkstra et al., 1972) y la eliminación de 
los enunciados de ramificación incondicional (go-to) de los lenguajes de programación 
de alto nivel. 

En un sistema orientado a aspectos, es imposible la lectura de código secuencial. 
El lector debe examinar cada aspecto, comprender sus puntos de corte (que pueden ser 
patrones) y el modelo de punto de enlace del lenguaje orientado a aspectos. Al leer el 
programa, tiene que identificar todo punto de enlace potencial y entonces cambiar la 
atención al código de aspecto para ver si puede tejerse en dicho punto. Luego, su aten- 
ción regresa al flujo principal de control del código base. En realidad, esto es cognitiva- 
mente imposible y la única forma de inspeccionar un programa orientado a aspectos es 
mediante el uso de herramientas de lectura de código. 

Pueden escribirse herramientas de lectura de código que “aplanen” un programa 
orientado a aspectos y presenten un programa al lector con los aspectos “tejidos” en el 
programa en los puntos de enlace especificados. Sin embargo, ésta no es una solución 
completa al problema de lectura de código. El modelo de punto de enlace en un lenguaje 
de programación orientado a aspectos puede ser dinámico en vez de estático, y quizá sea 
imposible demostrar que el programa aplanado se comportará exactamente de la misma 
forma que el programa que ejecutará. Más aún, como es posible que diferentes aspectos 
tengan la misma especificación de punto de corte, la herramienta de lectura de programa 
debe saber cómo el tejedor de aspectos maneja dichos aspectos “en competencia” y cómo 
se ordenará la combinación. 

Las pruebas de caja blanca o pruebas estructurales son un enfoque sistemático a las 
pruebas donde se usa el conocimiento del código fuente del programa para diseñar prue- 
bas de defecto. La meta es diseñar pruebas que proporcionen algún nivel de cobertura de 
programa. Esto es, el conjunto de pruebas debe garantizar que se ejecute toda ruta lógica a 
través del programa, con la consecuencia de que cada enunciado de programa se efectúe al 
menos una vez. Pueden usarse analizadores de ejecución de programa para demostrar que 
se logra este nivel de cobertura de pruebas. 


586 Capítulo 21 m Ingeniería de software orientada a aspectos 


En un sistema orientado a aspectos, existen dos problemas con este enfoque: 


1. ¿Cómo puede usarse el conocimiento del programa para derivar sistemáticamente 
pruebas del programa? 


2. ¿Qué significa exactamente cobertura de prueba? 


Para diseñar pruebas en un programa estructurado (por ejemplo, pruebas del código 
de un método) sin ramificaciones incondicionales, usted puede derivar un gráfico de 
flujo de programa, que revele toda la ruta de ejecución lógica a través de dicho programa. 
Entonces se examina el código y, para cada ruta a través del gráfico de flujo, se eligen 
valores de entrada que harán que la ruta se ejecute. 

Sin embargo, un programa orientado a aspectos no es un programa estructurado. El 
flujo de control se interrumpe mediante enunciados “viene de” (Constantinos et al., 2004). 
En algún punto de enlace en la ejecución del código base, puede ejecutarse un aspec- 
to. El autor no está seguro de que en tal situación sea posible construir un diagrama de 
flujo estructurado. Por lo tanto, es difícil diseñar sistemáticamente pruebas de programa 
que garanticen la ejecución de todas las combinaciones de código base y los aspectos. 

En un programa orientado a aspectos, existe también el problema de decidir qué signi- 
fica “cobertura de prueba”. ¿Significa que el código de cada aspecto se ejecuta al menos 
una vez? Ésta es una condición muy débil, debido a la interacción entre los aspectos y el 
código base en los puntos de enlace donde se tejen los aspectos. ¿La idea de cobertura 
de prueba debe extenderse de manera que el código del aspecto se ejecute al menos 
una vez en cada punto de enlace especificado en el punto de corte del aspecto? En tales 
situaciones, ¿qué sucede si diferentes aspectos definen el mismo punto de corte? Se trata 
de problemas tanto teóricos como prácticos. Se necesitan herramientas para soportar las 
pruebas de los programas orientados a aspectos, que ayudarán a valorar la medida de la 
obertura de pruebas de un sistema. 

Como se estudiará en el capítulo 24, los grandes proyectos tienen por lo general un 
equipo de aseguramiento de calidad separado, que establece los estándares de las prue- 
bas y requiere un aseguramiento formal de que las revisiones y pruebas del sistema se 
completan bajo dichos estándares. Los problemas de inspeccionar y derivar pruebas para 
programas orientados a aspectos son una significativa barrera para la adopción del desa- 
rrollo de software orientado a aspectos en los proyectos de software grandes. 

Además de los problemas con las inspecciones y las pruebas de caja blanca, Katz 
(2005) identificó problemas adicionales en las pruebas de los programas orientados a 
aspectos: 


1. ¿Cómo deben especificarse los aspectos de manera que puedan derivarse pruebas 
para dichos aspectos? 


2. ¿Cómo pueden probarse los aspectos independientemente del sistema base con el 
que deben tejerse? 


3. ¿Cómo puede someterse a prueba la interferencia de aspectos? Como se estudió, la 
interferencia de aspectos ocurre cuando dos o más aspectos usan la misma especifi- 
cación de punto de corte. 


4. ¿Cómo pueden diseñarse pruebas de manera que se ejecuten todos los puntos de 
enlace de programa y se apliquen pruebas de aspecto adecuadas? 
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En esencia, estos problemas con las pruebas ocurren porque los aspectos están estre- 
chamente integrados con el código base de un sistema. Por lo tanto, son difíciles de 
probar en aislamiento. Puesto que están tejidos en un programa en muchos lugares dife- 
rentes, no podemos estar seguros de que un aspecto que funciona con éxito en un punto 
de enlace funcionará necesariamente en todos los puntos de enlace. Todos éstos siguen 
siendo problemas de investigación para el desarrollo de software orientado a aspectos. 


PUNTOS CLAVE 


E El principal beneficio de un enfoque orientado a aspectos al desarrollo de software es que 
soporta la separación de competencias. Al representar las competencias transversales como 
aspectos, las competencias individuales pueden entenderse, reutilizarse y modificarse sin 
cambiar otras partes del programa. 


© Elenredo ocurre cuando un módulo en un sistema incluye código que implementa diferentes 
requerimientos del sistema. El fenómeno relacionado de dispersión ocurre cuando la 
implementación de una sola competencia se dispersa a través de varios componentes en un 
programa. 


© Los aspectos incluyen un punto de corte (un enunciado que define dónde se tejerá el aspecto 
dentro del programa) y consejos (el código para implementar la competencia transversal). Los 
puntos de enlace son los eventos que se pueden referenciar en un punto de corte. 


© Para garantizar la separación de las competencias, los sistemas pueden diseñarse como 
un sistema central que implementa las principales competencias de las partes interesadas, y un 
conjunto de extensiones que implementan competencias secundarias. 


© Para identificar las competencias se puede usar un enfoque a la ingeniería de requerimientos 
orientado a puntos de vista, que permita recuperar los requerimientos de las partes interesadas 
e identificar la calidad de servicio transversal y las competencias de política. 


© Latransición de requerimientos a diseño puede hacerse identificando casos de uso, cada uno 
de los cuales representa una competencia de las partes interesadas. El diseño puede modelarse 
mediante una versión extendida del UML con estereotipos de aspectos. 


© Los problemas de inspeccionar y derivar pruebas para programas orientados a aspectos son 
una barrera significativa para la adopción del desarrollo de software orientado a aspectos en los 
proyectos de software grandes. 


LECTURAS SUGERIDAS 


“Aspect-oriented programming”. Este número especial del CACM cuenta con algunos artículos 
dirigidos a un público general, que son un buen punto de partida para leer acerca de la 
programación orientada a aspectos. (Comm. ACM, 44 (10), octubre de 2001.) 
http://dx.doi.org/10.1145/383845.383846. 


